Technique for configuring link layer entities for a handover

ABSTRACT

A technique of configuring link layer entities for a handover is described. In a method embodiment, the technique includes receiving from a recipient of protocol data units a supplemental status report for an existing ARQ connection in context with an imminent handover, determining service data units corresponding to buffered protocol data units taking into account information included in the supplemental report, and transferring the determined service data units to a link layer entity which is to establish a new ARQ connection to the recipient. The forced status synchronization that is based on the supplemental report prevents the transfer of service data units that have already been successfully received at the recipient.

FIELD OF THE INVENTION

The present invention generally relates to the field of handovers inmobile communication networks. In particular, the invention relates tohandovers between link layer entities having control of retransmissionmechanisms.

BACKGROUND OF THE INVENTION

Retransmission mechanisms, also known as automatic repeat request (ARQ)techniques, constitute an approach that addresses the loss of data onits way to the intended recipient. Such data loss can be the result ofunfavourable physical conditions such as interference, noise, ormultipath propagation.

ARQ techniques are based on status reports that are transmitted from arecipient of the data to indicate to the transmitter that individualdata units have either been successfully received (positiveacknowledgement) or lost (negative acknowledgement). Generally, therecipient generates the status reports event-based, timer-based orpoll-based according to specifications of the respective ARQ protocol.Status reports may for example be scheduled after receipt of apredetermined number of data units or at predefined points in time.

The transmitter evaluates the received status reports and then decidesabout the retransmission of individual data units that have not or notcorrectly been received at the recipient. Some ARQ techniques providefor an automatic retransmission of a data unit for which no positiveacknowledgement has been received within a predetermined time intervalafter the first transmission of the data unit.

With regard to the open systems interconnection (OSI) layer model, ARQtechniques are usually implemented on the data link layer (layer 2 orL2). The data link layer is located between the physical layer (layer 1or L1) and the network layer (layer 3 or L3) as indicated by theprotocol stack 10 shown on the left-hand side of FIG. 1.

The physical layer L1 defines the electrical and physical specificationsfor the network components involved in the data transfer. The data linklayer L2 provides the mechanisms to transfer data between the individualnetwork components and to detect and possibly correct errors that mayoccur in the physical layer L1. The network layer L3 performs networkrouting, flow control, segmentation/desegmentation, and error controlfunctions. The best known example of a L3 protocol is the Internetprotocol (IP).

Usually, there are one or more additional layers on top of the networklayer L3. In the example shown on the left-hand side of FIG. 1, theseadditional layers include a transport layer L4 configured according tothe transmission control protocol (TCP) and an application layer L7configured according to the file transfer protocol (FTP). While not partof the official OSI model, additional protocols may operate between thedata link layer L2 and the physical layer L1. These protocols aresometimes referred to as “layer 2.5” protocols.

In the exemplary configuration shown in FIG. 1, the data link layer L2is divided into two sub-layers, the radio link control (RLC) layer andthe medium access control (MAC) layer, respectively. The ARQ techniquesare in most cases implemented within the RLC sub-layer as will now beexplained in more detail with reference to the right-hand side of FIG.1.

In the configuration shown in FIG. 1, the RLC sub-layer includes a firstbuffer 12 interfacing the network layer L3 and a second buffer 14interfacing the MAC sub-layer. The first buffer 12 is provided forstoring incoming service data units (SDUs) such as IP packets 16generated within the network layer L3. The SDUs stored in the firstbuffer 12 are read out by a segmentation engine 18 that segments theSDUs 16 into RLC protocol data units (PDUs) 20. The PDUs 20 are on theone hand forwarded to the MAC sub-layer for transmission to the intendedrecipient and, on the other hand, stored in the second buffer 14 for apossible re-transmission under the regime of an ARQ protocol.

At a certain point in time, a recipient of the PDUs may require ahandover from a first network component (with a link layer entity havingan RLC configuration as shown in FIG. 1) to a second network component(with a similar link layer entity). In the following, some possiblehandover scenarios will exemplarily be described with particularreference to processes occurring on the data link layer.

In principle, the handover from a currently serving link layer entity toa new link layer entity can occur without previous buffersynchronisation as shown in FIG. 2. In this case, when the handover isto be performed between two link layer entities, the stream of SDUs isswitched from the previously serving link layer entity to the new linklayer entity, and the content of the buffers 12, 14 of the previouslyserving link layer entity is simply discarded. It is evident that theresulting loss of buffered content will slow down the operation ofhigher layers and can result in a temporal degradation of the servicequality.

According to an alternative handover scenario shown in FIG. 3, thehandover can be performed such that before switching the SDU stream fromthe currently serving link layer entity to the new link layer entity,the content of the SDU buffer 12 of the currently serving link layerentity is transferred to the SDU buffer 12′ of the new link layerentity. This process is sometimes also called L3 context transfer. Inthis case, only the content of the PDU buffer 14 of the previouslyserving link layer entity is discarded. US 2004/0146033 A1 illustratesan exemplary technique for such an L3 context transfer.

One drawback of the handover approach illustrated in FIG. 3 is the factthat the data loss resulting from discarding the content of the PDUbuffer 14 can still lead to a service degradation. Furthermore, the dataloss may trigger higher layer protocol interactions, for example withTCP in the transport layer L4. Such higher layer protocol interactionsare illustrated in FIG. 4. As can be gathered from the TCP trace shownin FIG. 4, several TCP segments are lost at the handover instant (seedark vertical line). The lost TCP segments will have to be retransmittedby TCP after the handover has occurred, which leads to a slowtransmission start after the handover.

Additionally, the loss of TCP segments at the handover instant mayresult in a TCP timeout. Accordingly, frequent handovers may lead to thesituation that a TCP sender is unable to attain a sufficiently highsending rate, thus leading to a radio link underutilization. Such aunderutilization scenario is shown by the trace of the TCP congestionwindow CWND illustrated in FIG. 5.

One solution to avoid the problems illustrated in FIGS. 4 and 5 would beto make the handover actually lossless. To this end, all data currentlybeing transmitted (and stored in the link layer PDU buffer) may bereconstructed. The SDUs reconstructed from the content of the PDU buffermay then be transferred to the new link layer entity in addition to thetransfer of the SDU buffer content as shown in FIG. 3.

However, it has been found that such a reconstruction approach can causeunintentional data duplication as shown in the TCP trace of FIG. 6. Thisdata duplication is a result of the fact that some of the reconstructedSDUs have already been successfully delivered to the recipient, but thecorresponding PDUs have not yet been deleted from the PDU buffer.

The duplication shown in FIG. 6 tends to interfere with higher layerprotocols such as TCP. TCP rejects two duplicate data packets withsending a TCP duplicate acknowledgement back to the TCP sender, whichleads to TCP error recovery. The duplicate acknowledgement leads to abehaviour of the TCP congestion window CNWD as shown in FIG. 7. Thisbehaviour indicates that the radio link is not fully utilized most ofthe time. Obviously, such an underutilization constitutes a waste ofavailable resources.

Therefore, there is a need for an improved handover technique on a linklayer level that is more compatible with ARQ protocols.

SUMMARY OF THE INVENTION

According to a first aspect, a method of configuring link layer entitiesfor a handover is provided, with the link layer entities receivingservice data units from a higher functional layer, converting theservice data units into protocol data units, and buffering the protocoldata units for transmission to a recipient under the regime of an ARQprotocol with status reports, wherein the status reports are indicativeof receipt of one or more protocol data units at the recipient. Themethod comprises the steps of receiving from a recipient of protocoldata units a supplemental status report for an existing ARQ connectionin context with an imminent handover, determining service data unitscorresponding to buffered protocol data units taking into accountinformation included in the supplemental status report, and transferringthe determined service data units to a link layer entity which is toestablish a new ARQ connection to the recipient.

This approach may be implemented in context with any ARQ technique,including sliding window ARQ, go-back (n) ARQ, range-based ARQ, andstop-and-wait ARQ. The supplemental status reports may be constituted bypositive acknowledgements, negative acknowledgements, or any other ARQmessages including information about the current status of the recipientin relation to previously transmitted protocol data units.

The supplemental status report allows for an ARQ synchronisation betweena link layer sender and a link layer recipient just before the handoveris performed. In some cases, the supplemental status report may beconsidered as an unscheduled report because it may be generated by therecipient in addition to the status reports that are generated in aregular transmission scenario, i.e. in a transmission scenario excludinga handover procedure.

In some cases, the method may comprise the further step of thesuspending transmission of service data units and/or protocol dataunits. This suspension preferably takes place in a close temporalrelationship with receipt of the supplemental status report. Accordingto a first option, transmission of protocol data units is suspended inresponse to receipt of the supplemental status report. According toanother option, the transmission of protocol data units is suspendedalready before receipt of the supplemental status report, for example inresponse to receipt of a notification relating to the imminent handover.

The method may additionally comprise the step of requesting thesupplemental status report from the recipient. If this requesting stepis performed by the link layer entity requiring the supplemental statusreport, transmission of the protocol data units may be suspended inclose temporal relationship (e.g. immediately before or after) thesupplemental status report is requested from the recipient. In onescenario, the step of requesting the supplemental status report isinitiated upon receipt of a notification relating to the imminenthandover.

The supplemental status report may be requested from the recipient invarious ways. The request for the supplemental status report may forexample be included in a dedicated link layer message that is sent tothe recipient. Additionally, or in the alternative, the supplementalstatus report may be requested via one or more radio resource management(RRM) messages. Alternatively, or in addition, the supplemental statusreport may be received via one or more RRM control messages.

According to one variation, the step of requesting the supplementalstatus report comprises sending a request instructing the recipient tounconditionally generate and transmit the supplemental status report. Ifsuch a request is received by the recipient, the recipient has todisregard any conditions potentially preventing or delaying thegeneration of a status report, such as a running status prohibit timer.

The step of determining the service data units preferably excludes suchservice data units that correspond to protocol data units correctlyreceived at the recipient (as indicated in the supplemental statusreport). To this end, the successfully transmitted protocol data unitsmay be deleted within the PDU buffer before initiating reconstruction.Thus, a more up-to-date reconstruction becomes possible because of thesupplemental status report and the resulting enforced ARQsynchronisation immediately preceeding an imminent handover.

According to a first option, the step of determining the service dataunits comprises reconstructing service data units from buffered protocoldata units taking into account the information included in thesupplemental status report. According to another option, the step ofdetermining the service data unit comprises selecting buffered servicedata units corresponding to buffered protocol data units taking intoaccount the information included in the supplemental status report. Theservice data units may be selected from the conventional SDU buffer(that is filled with the service data units received from the higherfunctional layer, such as the SDU buffer 12 shown in FIG. 1) or from aseparate SDU buffer including only such service data units that havealready been or are about to be segmented into protocol data units.

As previously mentioned, the service data units received from the higherfunctional layer may be buffered in a link layer buffer. In such ascenario, a data context may be created from all determined service dataunits (e.g. those service data units that have been reconstructed fromprotocol data units) and, additionally, from all conventionally bufferedservice data units. The transferred data context will therefore alsoinclude the service data units reconstructed or otherwise determinedtaking into account the information included in the supplemental statusreport. The data context thus created may then be transferred to thelink layer entity which is to establish (or has already beenestablished) the new ARQ connection to the recipient.

The present invention may be practised in the form of a softwaresolution, by one or more hardware components, or as a combinedsoftware/hardware approach. According to a software aspect, a computerprogram product is provided. The computer program product comprisesprogram code portions for performing the process steps when the computerprogram product is run on one or more computing devices. The computerprogram product may be stored on a computer readable recording medium.

As for a hardware aspect, a device for configuring link layer entitiesfor a handover is provided, the link layer entities receiving servicedata units from a higher functional layer, converting the service dataunits into protocol data units, and buffering the protocol data unitsfor transmission to a recipient under the regime of an ARQ protocol withstatus reports, wherein the status reports are indicative of receipt ofone or more protocol data units at the recipient. The device comprises afirst interface adapted to receive from a recipient of protocol dataunits a supplemental status report for an existing ARQ connection incontext with an imminent handover, a mechanism adapted to determineservice data units corresponding to buffered protocol data units takinginto account information included in the supplemental status report, anda second interface adapted to transfer the determined service data unitsto a link layer entity which is to establish a new ARQ connection to therecipient.

The device may be part of a system which additionally comprises arecipient having a reporting mechanism adapted to generate supplementalstatus reports for the existing ARQ connection. The device may beintegrated in or otherwise communicate with one or more link layerentities. The link layer entities may in turn be incorporated in networkcomponents that can comprise one or more further functional layers.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following, the invention will be described with reference toexemplary embodiments illustrated in the drawings, wherein:

FIG. 1 is a schematic diagram illustrating on the left-hand side aprotocol stack with a data link layer and on the right-hand side avarious mechanisms performed in the data link layer;

FIG. 2 is a schematic diagram illustrating a first handover procedurebetween two link layer entities;

FIG. 3 is a schematic diagram illustrating a second handover procedurebetween two link layer entities;

FIG. 4 shows a diagram illustrating data loss resulting from thehandover procedure illustrated in FIG. 3;

FIG. 5 is a diagram illustrating the timeout behaviour resulting fromthe data loss illustrated in FIG. 5;

FIG. 6 is a diagram illustrating data duplication resulting fromunnecessarily reconstructed SDUs;

FIG. 7 is a diagram illustrating a TCP behaviour in response toduplicate acknowledgements resulting from the data duplicationillustrated in FIG. 6;

FIG. 8 is a schematic diagram illustrating an embodiment of aconfiguration device according to an embodiment of the presentinvention;

FIG. 9 is a schematic diagram illustrating a system embodiment and ahandover procedure under control of the device of FIG. 8;

FIG. 10 is a schematic flow chart illustrating a method embodiment ofthe present invention;

FIG. 11 is a schematic diagram illustrating a further embodiment of thepresent invention; and

FIG. 12 is a diagram illustrating an improved TCP behaviour resultingfrom an implementation of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

In the following description, for purposes of explanation and notlimitation, specific details are set forth, such as particular sequencesof process steps, individual ARQ scenarios, and specific systemconfigurations in order to provide a thorough understanding of thepresent invention. It will be apparent to one skilled in the art thatthe present invention may be practised in other embodiments that departfrom these specific details. In particular, while the embodiments willbe described in a TCP/IP context, with regard to specific ARQmechanisms, and in relation to a data link layer having a certainconfiguration, it is to be understood that the invention can also beimplemented in context with other protocols and configurations.

Moreover, those skilled in the art will appreciate that the functionsexplained herein below may be implemented using software functioning inconjunction with a programmed microprocessor or general purposecomputer, and/or using an application specific integrated circuit(ASIC). It will also be appreciated that while the current invention isprimarily described in the form of methods and devices, the inventionmay also be embodied in a computer program product as well as in asystem comprising a computer processor and a memory coupled to theprocessor, wherein the memory is encoded with one or more programs thatmay perform the functions disclosed herein.

FIG. 8 shows an embodiment of a device 80 for configuring link layerentities for a handover. The device 80 includes a first interface 82that is adapted to receive (in context with an imminent handover) asupplemental status report from a recipient of protocol data units.Thus, the supplemental status report is tied to the handover procedure.The status report pertains to an existing ARQ connection stretchingbetween a first link layer entity and the recipient. The supplementalstatus report can be received via the first interface 82 in addition toregular status reports generated by the recipient in accordance with aconventional ARQ protocol.

The device 80 further comprises a mechanism 84 adapted to determine(e.g. reconstruct or select) service data units corresponding tobuffered protocol data units based on information included in thesupplemental status report. This information can be indicative ofsuccessful and/or failed receipt of one or more protocol data units atthe recipient. The supplemental status report thus allows for asynchronization between the recipient and the first link layer entity incommunication with the recipient via the existing ARQ connection. Thissynchronization helps to avoid the transfer of service data units thatcorrespond to buffered protocol data units already successfully receivedby the recipient but not yet acknowledged by way of “regular” statusreports.

Additionally, the device 80 includes a second interface 86 adapted totransfer the service data units determined by the mechanism 84 to asecond link layer entity that is to establish a new ARQ connection tothe recipient in context with the handover.

This handover will now be explained in more detail with reference toFIG. 9.

FIG. 9 shows a network system 90 comprising two link layer entities 92,94, a (common) controller 88 for the link layer entities 92, 94, and arecipient 96. Each of the two link layer entities 92, 94 and therecipient 96 have a protocol stack with a data link layer that can besimilar to the one shown in FIG. 1. Further, each of the link layerentities 92, 94 comprises a device 80 as shown in FIG. 8 forimplementing the required handover configurations.

In one exemplary realization, the link layer entities 92, 94 areincluded in base stations or nodes B in accordance with the universalmobile telecommunications system (UMTS) standard. The controller 88 canbe configured as a UMTS radio network controller (RNC). In the UMTScontext, the recipient 96 may take the form of a user equipment (UE)such as a mobile telephone. Alternatively, the link layer entities 92,94 may be integrated together with the controller 88 into a single RNCcomponent.

It should be noted that the device 80 and the link layer entities 92, 94could be implemented either on the terminal side such as within an UE(uplink) or on the network side (downlink). In a terminal scenario, thetwo link layer entities 92, 94 may for example constitute two differentPCMCIA cards coupled to one and the same terminal such as a portablecomputer. Alternatively, the two link layer entities 92, 94 could beintegrated in a dual mode terminal operative according to at least twowireless communication standards such as UMTS and GSM (Global System forMobile Communications).

As can be seen from FIG. 9, there exists an ARQ connection 98 stretchingbetween the first link layer entity 92 and the recipient 96. The ARQconnection 98 constitutes a data and/or control channel with ARQfunctionalities. Due to a possible mobility of the recipient 96 or othercircumstances, a handover between the first link layer entity 92 and thesecond link layer entity 94 may be required at a certain point in time.In the course of the handover, a new ARQ connection 100 will beestablished between the second link layer entity 94 and the recipient96. After (or, in an alternative embodiment, before) the new ARQconnection 100 has been established, the existing ARQ connection 96between the first link layer entity 92 and the recipient 96 may beterminated. In the course of the handover procedure, a data context willbe transferred between the first network entity 92 and the second linklayer entity 94 as indicated by the arrow 102. The data context may betransferred between the link layer entities 92, 94 directly or via thecontroller 88.

In the following, the communication between the four network components88, 92, 94, 96 shown in FIG. 9 will be described with reference to theflow chart 1000 of FIG. 10, and from the perspective of the first linklayer component 92.

The first link layer entity 92 constantly receives service data unitsfrom a higher functional layer, such as a network layer L3, arranged inthe controller 88 or any other network component. The link layer entity92 converts these service data units into protocol data units andbuffers the protocol data units for transmission under the regime of anARQ protocol to the recipient 96. The ARQ protocol specifies regularstatus reports indicative of receipt of one or more protocol data unitsat the recipient 96.

Referring now to FIG. 10, the first link layer entity 92 receives in afirst step 1010 from the recipient 96 a supplemental status report forthe existing ARQ connection 98 in context with an imminent handover ofthe recipient 96 from the first link layer entity 92 to the second linklayer entity 94.

In a second step 1020, the first link layer entity 92 determines (e.g.reconstructs or selects) service data units corresponding to bufferedprotocol data units taking into account status information included inthe supplemental status report received from the recipient 96.

In a further step 1030, the first link layer entity transfers a datacontext including at least the service data units determined in step1020 to the second link layer entity 94 as indicated by arrow 102.Additionally, the controller 88 will switch the service data unit streamfrom the first link layer entity 92 to the second link layer entity 94.The second link layer entity 94 will then start to transmit protocoldata units via the new ARQ connection 100 to the recipient 96 takinginto account the data context received from the first link layer entity92.

In the following, a further embodiment of the invention will bedescribed with reference to the schematic diagram shown in FIG. 11. Theembodiment shown in FIG. 11 can be combined with any one of theembodiments described with reference to FIGS. 8 to 10.

The process schematically illustrated in FIG. 11 is initiated whendetecting (e.g. by the controller 88 shown in FIG. 9) that a recipientof a PDU stream requires a handover from a currently serving link layerentity (left-hand side of FIG. 11) to a new link layer entity(right-hand side of FIG. 11). In this case the currently serving linklayer entity is immediately notified of the imminent handover. Thisnotification triggers a state synchronisation between the currentlyserving link layer entity and the PDU recipient (not shown in FIG. 11).The state synchronisation can be performed in various ways.

In one embodiment, the currently serving link layer entity (e.g. the RLCsub-layer) sends a newly defined link layer message (in the followingcalled Super-Poll Request) to the PDU recipient. The PDU recipientreplies to the Super-Poll Request with generation of a supplementalstatus report and with transmission of this status report to thecurrently serving link layer entity. What differentiates a Super-PollRequest from a regular link layer poll is the fact that the Super-PollRequest instructs the recipient to generate and transmit the statusreport in any case (e.g. even if the local status prohibit timer isrunning).

In order to reduce the overall messaging, the handover-relatedSuper-Poll Request may be substituted by a “default request” included asan additional setting of the handover procedure (that is typicallyperformed via RRM messages of a radio resource control (RRC) protocol).In this case, the supplemental status report may automatically begenerated and transmitted from the recipient that has been notified ofthe imminent handover within a dedicated or a handover-related RRMmessage. Accordingly, the status report for a link layer connection thatis to be migrated can be included in a RRM message instead of sending it(e.g. as in the Super-Poll Request scenario discussed above) as aseparate link layer message.

In context with receiving the handover notification and/or in contextwith generating and sending a supplemental status request, the currentlyserving link layer entity may optionally suspend PDU transmission to therecipient. In addition, or alternatively, the transmission of SDUs tothe currently serving link layer entity may be suspended.

In response to receipt of the supplemental status report from therecipient, the currently serving link layer entity updates itstransmission state. This updating step may include deleting ordiscarding any PDUs in the PDU buffer 14 shown in FIG. 11 that arepositively acknowledged in the supplemental status report.

In a next step, the currently serving link layer entity reconstructsSDUs from the updated PDU buffer 14 for context transfer. It should benoted here that the reconstruction is only started after the content ofthe supplemental status report has been considered. In an alternativeembodiment, the SDUs are not reconstructed from the updated PDU buffer14, but selected from the SDU buffer 12 (in which case the SDUs readfrom the SDU buffer 12 for segmentation will be appropriately marked butnot deleted from the SDU buffer 12), or selected from a dedicated SDUbuffer (not shown) in which the SDUs which have been read out forsegmentation are temporarily stored for the generation of ahandover-related data context. In the selection scenario, those SDUsthat are acknowledged in the supplemental status report will not beselected for data context generation.

In the reconstruction scenario, the currently serving link layer entitycreates a data context from all SDUs that are stored in the SDU buffer12 and additionally from those that have been reconstructed from theupdated PDU buffer 14. The data context including the buffered andreconstructed SDUs is then forwarded to the new link layer entity asindicated by the two arrows in FIG. 11. At the new link layer entity,the SDUs included in the data context are stored in the local SDU buffer12′. Consequently, this SDU buffer 12′ will also include SDUscorresponding to PDUs reconstructed from the updated PDU 14 of thecurrently/previously serving link layer entity.

In a final step, the SDU stream is switched to the new link layer entityas shown in FIG. 11, and the new link layer entity starts to transmitPDUs to the original recipient via a newly established ARQ connection.

As has become apparent from the above description, the embodiments allowfor a lossless handover without duplication of SDUs that have alreadybeen successfully transmitted. As a consequence, negative interactionswith higher layer protocols such as TCP can be avoided as illustrated inthe diagram of FIG. 12. As can be gathered from FIG. 12, the congestionwindow CWND is only throttled by SDU buffer overflow, but nointerference with TCP due to unintentional data duplications athandovers can be noticed.

It should be noted that the present invention is applicable to a widevariety of handover scenarios. These scenarios include intra-systemhandovers, inter-system handovers between different radio technologies(e.g. access switches), handovers between different access gateways inthe long term evolution (LTE) project of the third generationpartnership project (3GPP), and handovers between 3GPP LTE release 7 andpre-release 7 3GPP access. Additionally, the serving radio networksystem (SRNS) relocation mechanism within 3GPP networks can be improvedfor inter-RNC handovers.

It will be appreciated by those skilled in the art that theabove-described embodiments may be adapted or extended in various ways.While the foregoing description thus makes reference to preferredembodiments, the scope of the invention is defined solely by the claimsthat follow and the elements recited therein.

The invention claimed is:
 1. A method of configuring link layer entitiesfor a handover, the link layer entities receiving service data unitsfrom a higher functional layer, converting the service data units intoprotocol data units and buffering the protocol data units fortransmission to a recipient under the regime of an ARQ protocol havingstatus reports, the status reports being indicative of receipt of one ormore protocol data units at the recipient, the method comprising thesteps of: receiving from a recipient of protocol data units asupplemental status report for an existing ARQ connection in contextwith an imminent handover; determining service data units correspondingto buffered protocol data units taking into account information includedin the supplemental status report; and transferring the determinedservice data units to a link layer entity for establishing a new ARQconnection to the recipient.
 2. The method of claim 1, furthercomprising the step of suspending transmission of protocol data units ina close temporal relationship with receipt of the supplemental statusreport.
 3. The method of claim 1, further comprising the step ofrequesting the supplemental status report from the recipient.
 4. Themethod of claim 3, wherein the step of requesting the supplementalstatus report is initiated upon receipt of a notification relating tothe imminent handover.
 5. The method of claim 3, wherein the step ofrequesting the supplemental status report includes sending a dedicatedlink layer request message to the recipient.
 6. The method of claim 3,wherein the step of requesting the supplemental status report isimplemented as a handover setting on the side of the recipient.
 7. Themethod of claim 3, wherein at least one of the steps of requesting andreceiving the supplemental status report is performed via one or moreradio resource management messages.
 8. The method of claim 1, whereinthe step of determining service data units excludes such service dataunits that correspond to protocol data units correctly received at therecipient.
 9. The method of claim 1, wherein the step of determiningservice data units corresponding to buffered protocol data unitscomprises reconstructing service data units from the buffered protocoldata units.
 10. The method of claim 1, wherein the step of determiningservice data units corresponding to buffered protocol data unitscomprises selecting service data units from a buffer.
 11. The method ofclaim 3, wherein the step of requesting the supplemental status reportcomprises generating a request instructing the recipient tounconditionally generate the supplemental status report.
 12. The methodof claim 1, further comprising the step of buffering the service dataunits prior to conversion.
 13. The method of claim 12, furthercomprising the steps of: creating a data context from all bufferedservice data units and all determined service data units; andtransferring the data context to the link layer entity which is toestablish the new ARQ connection to the recipient.
 14. A device forconfiguring link layer entities for a handover, the link layer entitiesreceiving service data units from a higher functional layer, convertingthe service data units into protocol data units, and buffering theprotocol data units for transmission to a recipient under the regime ofan ARQ protocol having status reports, the status reports beingindicative of receipt of one or more protocol data units at therecipient, the device comprising: a first interface adapted to receivefrom a recipient of protocol data units an supplemental status reportfor an existing ARQ connection in context with an imminent handover; aprocessor configured to determine service data units corresponding tobuffered protocol data units taking into account information included inthe supplemental status report; and a second interface adapted totransfer the determined service data units to a link layer entity whichis to establish a new ARQ connection to the recipient.
 15. A systemcomprising: a device, in communication with one or more link layerentities, for configuring link layer entities for a handover, the linklayer entities receiving service data units from a higher functionallayer, converting the service data units into protocol data units, andbuffering the protocol data units for transmission to a recipient underthe regime of an ARQ protocol having status reports, the status reportsbeing indicative of receipt of one or more protocol data units at therecipient, the device comprising: a first interface adapted to receivefrom a recipient of protocol data units an supplemental status reportfor an existing ARQ connection in context with an imminent handover; aprocessor configured to determine service data units corresponding tobuffered protocol data units taking into account information included inthe supplemental status report; and a second interface adapted totransfer the determined service data units to a link layer entity whichis to establish a new ARQ connection to the recipient and a recipienthaving a reporting mechanism adapted to generate supplemental statusreports.